We'll see you next time.
See you next time.
See you next time.
I've come to DEF CON, I think this is my fourth year, to talk about whatever random shit I want to talk about.
So, today what it says on the schedule I'm going to talk about is a paper called Arranging an Anonymous Rendezvous, or Privacy Protection for Internet Servers.
And the idea here is to extend the realm of privacy.
Privacy from that of the consumer, there are a number of systems out there, including Freedom, Onion Routing, things like Freenet, and others that...
And a pen.
Okay, this talk will now go much better, because I can draw things.
Right, extend systems which provide for client-side anonymity, which is something...
Describe in more detail.
And allow them to be used to provide for server-side anonymity.
So, instead of just being private when you use an internet service, you as the provider of a service can also remain private.
Keep your identity, your IP address hidden.
And I'll talk about a little why this is a useful thing to do.
Now, it's really early in the morning.
I mean, 11 a.m. is not supposed to be really early, but...
Yeah.
You all know what we were doing last night.
I had to duck out of my own party early so I can get some sleep and come here this morning.
So, I want this to be more of a kind of interactive session here.
So, if you have, like, any questions at any point on pretty much any topic, just do this, and I'll shine a green light in your eyes.
And then speak really loudly to ask a question, or to make a comment, or something.
Okay.
And if you ask a question I have no idea the answer to, I'll just bullshit, and you won't know.
What's that?
So, the folks at the back can see.
Okay.
Well, I have to carry all my shit up here now.
I can't turn the mic...
Oh, they can turn the mic up.
Woo-hoo.
Oh, I can't, actually, because I need this.
Well, I guess that can be moved up, too.
Okay.
So, while I'm moving this, I'll just...
Stick it over.
Okay.
How's that?
Excellent.
Yeah.
Just toast the chair entirely.
I'll stand.
Okay.
Okay.
I'll just start by talking about what I'm supposed to talk about, and if you want me
to talk about something else, because you think that's more interesting, just jump in.
So, one of the most useful aspects of the Internet are the services on it, right?
The Internet would be kind of useless if you had this great network of machines all
hooked up together, but they were all clients.
And there was no actual services out there, right?
You can get some peer-to-peer stuff going, email would probably work, but the whole
World Wide Web idea wouldn't have happened.
So, what's that?
So, it did.
So, we have these great services, and we want to be able to use them, and we have this
problem that I'm sure you're all familiar with.
If you rewind your...
Your mental clock back maybe about 10 years, or even a little less than 10 years before
the World Wide Web really happened, and back to when it was just a bunch of us .edu geeks
on the system talking to other .edu geeks, basically, the Internet was not designed with
the idea of adversaries in mind.
Right?
The Internet was designed with the idea that everyone on it is cooperative and friendly,
and it's okay to have protocols like rlogin, right?
We've whacked them down.
So, lately, since the mid-90s, it's become clearly evident that there are adversaries
on the Internet.
How many here are adversaries?
So, we need new protocols that design security into the system, and those things have happened.
We now have SSH.
We have a lot of cryptography, and that's all great.
Now what we're seeing is that, oh, security isn't all we really want.
We want protocols to have good privacy properties as well, and what I mean by privacy properties
is that a protocol might inherently reveal a lot of information about you.
For example, any time you use IP, there's a source address in every IP packet you send
out.
So that means, basically, no matter what you want, if you want to speak IP or TCP IP to
another host, you've really got to tell them where on the Internet you are.
And that correlates highly to your identity.
The first thing I'm going to draw, I think, to give you a good idea of what's involved
here is something we call the Nimity Slider.
And the idea of the Nimity Slider, I wonder if I can keep this page from blowing away.
Oh, well, maybe not.
The idea of the Nimity Slider is it's a way to integrate.
It's to indicate how much information about your identity is revealed in any given transaction.
So what I mean by that is, at the high end, we have what we call veranimity, which just
means true name.
This is a transaction.
A transaction would be put here if, when you do the transaction, you necessarily have
to give out some piece of information.
Give information that strongly correlates to your identity.
It could be your name, it could be your phone number, it could be your credit card number,
it could be your SSN, anything that basically is easy to take and look up and turn into
a unique person.
So examples of veranimous transactions are going online and buying something with a credit
card.
You give your credit card number, and that credit card number encodes a whole bunch of
things about your identity.
All the way at the other end, there's what we call ... I'll stop scribbling.
Unlinkable anonymity.
The idea of unlinkable anonymity, or complete anonymity, is that you can do the transaction
and no information about your identity is revealed.
That's what we call veranimous transactions.
It's not even the case that if you come back a week later and do another transaction with
the same merchant that he can tell that you'd been there before, or that that transaction
and the transaction of a week ago were by the same person.
So a simple example of this is going into a store and paying for something with cash.
Now there are all these security camera issues and things like this that might make the transaction
not actually anonymous, but we'll ignore those.
And we'll just focus on the properties of the transaction.
So you come in wearing a paper bag over your head, and you pay cash, and you leave, and
next week you come in with a different paper bag over your head, and you pay cash again,
and there's no way for the shopkeeper to tell, well, depending on how many customers
routinely come in wearing paper bags, that these two transactions were done by the same
person.
So that's what we call unlinkable anonymity.
So as usual in any kind of slider-esque system, the interesting points aren't the endpoints.
The endpoints are the extreme versions of whatever you're talking about, and most of
the real-life examples are somewhere in the middle.
So above unlinkable anonymity, we have what we call linkable anonymity, and the idea
of linkable anonymity is that it's just the same, there's no information about the transaction,
presented...
about your identity presented in the transaction, but the merchant a week from now when you come in
can identify that you were the same person as you were last week. An easy example of this is using
one of those frequent buyer cards. You go to the shop, you have your paper bag, and you pay with
cash, and then you flash them your Coke card. That has a unique serial number on it. Now,
when you signed up for this card, it might have asked you for your name and address,
and you wrote down Mickey Mouse, 101 Storybook Lane, or whatever, and you lie.
Honestly, they don't care. They care not at all about what name you put on that card.
The information they want is they want to be able to track your purchases, so they know
you bought, how often you buy beer, and things like this.
Right. Coke cards, Safeway Club cards, all these things provide for linkable anonymity.
Above that, we have a point called persistent pseudonymity. I think this is one of the most
interesting places to put a protocol. If you're going to design a protocol, this is an interesting
place to design it. What I mean by persistent pseudonymity is that the transaction does have
an identifier for you in it, but that identifier is not linkable to your real-world meatspace
identity. Moreover, you can have more than one.
Okay, so the big difference between this one and this one...
between pseudonymity and veronymity is basically you only have one real name, right?
If somehow that real name gets tarnished, like someone does identity theft on you or something like this,
you're in a lot of trouble, right?
Your credit report is pretty hard to keep clean, to re-clean if it's been altered.
With persistent pseudonymity, you can have multiple identities.
And this also lets you do things like separate out different aspects of your life.
If you post a resume to a job search site, you can do it under one identity.
And if you post a personal ad to an online dating site, you can do it under another identity.
And search engines should not be able to correlate that to the resume, right?
At least that's the goal.
So...
One...
One...
One of the great...
One of the fundamental properties of the slider, which is what's important to this talk,
is that it's actually more of a ratchet than a slider.
It's easy to move up and hard to move down.
And what I mean by that is that if I give you a protocol that inherently has a low level of nimity in it,
okay, so the paying with cash protocol,
if for some reason the shopkeeper and I want to agree
that maybe he'll give me a discount if I give him some hint about my identity
or show him my buying patterns or something like this,
then we can negotiate that, and it's very simple to add nimity.
I just show him my identity, or I show him my club card, or something like this.
Right?
So I can easily take a protocol that inherently has a low level of identity revealed in it
and add identity just by, in addition to performing the protocol,
you just show your identity.
Very simple.
On the other hand, today, basically, the only real way to buy something online is with a credit card.
And credit card, as I mentioned, is pretty much veranimous.
How would you go about changing that protocol to buy something online without revealing your identity?
This seems to be a much harder problem.
You have to start going back and reworking how credit cards work
and maybe issue you different credit cards.
Some of them don't have your identity linked to them,
but still look like a valid credit card.
And it's not anywhere nearly as simple as just you show your identity,
which is how you move up.
So the lesson to be taken away from the nimity slider
is that when you're designing a new protocol,
you should always design it with as low a nimity level as possible,
even lower than you think you need.
As I mentioned, persistent pseudonymity,
is a good place to put things.
I mentioned the differences with veranimity.
The differences with anonymity
is that persistent pseudonymity,
you can gain what we call reputation capital,
or in general, just reputation.
If people just post anonymous messages over and over again,
and those messages aren't linkable together,
so you don't know that they're the same person posting them,
then that poster never gains any reputation.
When another anonymous message,
comes in, you can't tell is this person this clever person
that's been posting these things,
or is it this nutcase, right?
You have no idea,
and you have to take each message at its face value.
But if you have persistent pseudonymity,
you can have,
basically, you learn that this pseudonym
posts things you agree with,
you think he's clever, insightful,
and this pseudonym is like some random guy
talking about how Venus should be,
should be moved to the orbit of Earth to create,
yeah, something, you get that.
So, yeah.
So, it's a good question.
What's the difference between persistent pseudonymity
and linkable anonymity?
Basically, what I mean there by the difference
is that in persistent pseudonymity,
you're generally given an explicit identifier.
So, you have some false name,
you can be used generally where a regular name can be used.
So, like an email, the from line could contain a pseudonym.
With linkable anonymity,
the transactions are linkable together,
so you could assign the pseudonym of the form,
I am the same person who did this transaction
on this particular date at this particular time, right?
But it's not a,
a name that generally would be used to build reputation
or be used in contexts where veronyms are normally used.
So, the advantage of having something like pseudonymity
just a little lower than veronymity
is often you can use the same mechanisms that we use today
that expect veronyms,
but you just stick a pseudonym in instead.
So, if I'm filling out a form online,
it's asking me for my name, my age, and stuff,
and I can fill that in.
fill in incorrect but consistent information every time I go there.
That would be a pseudonym.
Linkable anonymity is, they don't ask for that even, but they have some kind of way
to track you, like with a cookie, and they just link together all your transactions themselves.
It's merely a difference in the way it's observed and not so much in the fundamental mathematics
of it.
Okay.
Yeah?
Right, it's a good question. Just repeating quickly, the question was, it's good from a technical standpoint,
but governments certainly aren't going to want you to have multiple identities.
They really hate it when you have multiple driver's licenses and passports and things like this.
So is this really going to happen?
The answer is, it will happen first in places that aren't governments, right?
So, governments might insist you have a single national ID card, and some countries have that.
The U.S. basically has that nowadays with the new requirements on driver's licenses and things like this.
But it turns out that recently we've seen new legislation coming through that's very privacy-friendly in many jurisdictions.
The most recent example is in...
Up in Canada, where I'm from, we just passed Bill C-6 into law,
and that has a whole bunch of really privacy-friendly ramifications for consumers.
And we have a Privacy Commission in Canada.
It's a branch of the government whose job it is to protect individuals' privacy.
You don't have that here in the U.S.
Duh. What a shocker.
So, certainly...
Certainly, you might believe governments will come into the pseudonymity idea
sort of maybe in more enlightened countries first.
Yeah, Brad.
Okay, that's a good question.
The question was, what level of nimity...
...do we believe the anonymous remailers and hushmail provide?
So, as always, when you're looking at the level of nimity of something,
you have to say with respect to whom.
Right?
When I'm doing a transaction with a shop,
the shop might learn my identity, but the guy standing next to me in line might not.
Right?
So you have to ask, who is your adversary?
Who gets to learn this information?
So, for example, with hushmail,
hushmail certainly learns your identity because you connect to them with TCP.
Right?
So they learn your IP address.
If they do their job right, then no one else should learn your identity.
So that's what we generally call a trust-me system.
Some company, namely hushmail in this case, says,
trust me, give me your personal data, and I promise not to release it.
And then there's usually a lot of fine print.
Like, well, unless someone comes to us with a warrant, or a subpoena,
or a rubber hose, or a gun to our head, or something like this.
And then they will release it.
So the better answer when you're designing a system,
if you want to be one of those providers,
the better answer is not to have that information at all,
which will be a theme when I actually get into the content of the paper.
Right?
Right.
Right.
Right.
Right.
Right.
They come at you with all the, like, rubber hoses they want,
and you can't give them any information.
So your best strategy is to make it extremely well known
that you don't have this information,
so that you're not inconvenienced by people showing up in the middle of the night
with batches of rubber hoses.
I mean, if you like people showing up in the middle of the night
with batches of rubber hoses, well, you should move to San Francisco.
Yeah.
Yeah.
Right.
Right.
So the comment being made is that it's not just Hushmail which learns your identity.
It's the people on the way, the backbones, the routers.
Now, in one sense that's right, in one sense that's not.
What the people along the way learn is that you are a Hushmail user.
They don't learn which one
because the communication between you and HatchMail is encrypted.
So they never find out which HatchMail user you are.
So, yeah, at this point, I think it'll be useful to draw a little diagram of protection layers.
So when Alice wants to send to Bob a message over the Internet,
she can protect it in a number of ways.
The simplest thing is do nothing.
Alice sends the message to Bob.
Anyone on the Internet basically can read that message, tell what Alice is sending to Bob.
That's basically the way email works today.
Above that,
Alice can use encryption.
And the goal of encryption is to protect the message data, the contents of the message.
So the eavesdropper Eve will see that Alice is sending a message to Bob,
but it'll be scrambled and Eve can't read it.
And this is basically the state of technology for the last little while.
We understand encryption.
PGP is your friend.
SSH is your friend.
And we know how to protect contents of our messages from interception.
The next level up, let's say Alice and Bob are like CEOs of big firms,
and suddenly they start exchanging encrypted information.
Eve notices this, right?
Even though Eve can't read the message,
Eve can gain a lot of information and potentially useful insider trading information
just from the fact that these two...
These two CEOs have started regularly communicating.
So now what we want to protect is not the data of the message, but the metadata.
The metadata are the headers.
Things like the from address, the to address, the subject.
Oh, rock.
Great.
Great.
So for that layer, we use things called PETs, or privacy-enhancing technologies.
And those are technologies whose goal it is to not hide the data in the message, but the metadata.
And it could be some or all.
And it could be your choice as to what metadata it hides.
Now let's say that Alice wants to hide something even stronger.
So instead of just hiding the data in the metadata...
So here the attacker might see, let's say, the particular PET you're using is just hiding the destination.
So if Eve, the eavesdropper, looks at the internet,
what she sees is that Alice is sending a message, but it's scrambled, and she can't read it.
And even the destination address is scrambled, and she can't read it.
And it's just going to someone, but she doesn't know who.
But now let's say that Alice is a human rights worker in a less-than-friendly country.
And, of course, the telecommunications infrastructure is owned by the less-than-friendly country's government.
And it would not be a happy thing if they found out Alice, this human rights worker,
was sending a lot of encrypted email to unknown addresses.
So what you really want to do is hide the entire egress,
the entire existence of the message.
And for that, we use a technique known as steganography.
And with steganography, not only are the data and the metadata hidden,
but, in fact, the entire existence of the message is hidden from an attacker.
So there are all sorts of techniques to do this, like hiding messages in other innocuous messages.
Like, take your email message.
And the number of spaces after every period encodes the bits of your other message.
And does it in an encrypted fashion.
So these are the layers Alice can usefully do.
I'm going to talk about primarily privacy-enhancing technologies.
Encryption is done.
We basically totally understand encryption.
Right?
I mean, that's a pretty strong statement.
But if you look at where we were in the 60s,
basically,
the spooks knew lots and lots about encryption.
And the public research community knew basically nothing.
Fast forward 40 years.
Now, we're basically pretty caught up to the spooks, we think.
We understand the fundamentals of encryption, how encryption works,
public-key encryption, symmetric-key encryption.
There are probably some things we're missing,
but the tools we have are probably good enough for whatever reason.
We can do whatever we want to use.
On the other hand, privacy-enhancing technologies and the field devoted to attacking privacy-enhancing technologies
is called traffic analysis.
With traffic analysis, the state we are in today is pretty much the state we were in with crypto in the 60s.
The spooks have been doing this forever.
Traffic analysis is their big thing.
Right?
Even if they can't read the encrypted messages,
they still use the fact that a message was sent from here to here,
and one from here to here,
and one from here to here,
and they work out,
oh, this must be their headquarters,
and this is where their field generals are sitting,
and can do all sorts of clever things.
And you can read a little bit about that in the public literature,
but not a lot.
And in the public literature, we basically know almost nothing about traffic analysis.
And hopefully that will change in the same way that the state of knowledge of crypto changed.
Over the last 40 years.
And maybe it will take another 40 years for us to know as much about traffic analysis
as we know about block ciphers today.
So, this is where the current research is.
In privacy-enhancing technologies, traffic analysis,
and both how to do traffic analysis and how to protect from traffic analysis.
So, we're going to talk about PETs.
So, these internet services I mentioned earlier,
you can have like some common internet services,
you can have chat rooms, online shops, mailing lists,
say something more detailed like age verification services.
So, there are lots of, wow, we're going to blow away here.
So, there are lots of things that,
are offered online that you might want to use.
And you might want to use it privately, right?
If, say, in a chat room, you might be in a spousal support group.
On shops, you might be wanting to buy medication online.
You might want to participate in certain subculture mailing lists.
Or you might want to use an age verification service to let you into a porn site.
All these examples are particular cases
of where the customer might want privacy of his identity, right?
He might want to control who gets to learn his identity
when he's participating in BDSM mailing lists or something like this.
So, that's great.
And the technologies to do that are in their infant stages right now,
but they're out there, right?
I mean, my own company has the Freedom System for doing things like this.
There are other things like FreeNet.
There's the Freehaven, Onion Routing.
Basically, there are a number of services coming up now
to let you use internet services without revealing, necessarily, your identity.
But what if you're the operator of, say,
a chat room, let's say,
a shop that talks about drugs,
or you're a shop that offers Nazi memorabilia online,
or you have a mailing list of political distance
that you run for a country like China,
or you provide age verification services
that might let you into websites
that contain illegal content in some countries, right?
Now, none of those examples is made up.
All of those examples are real examples
of things that, within the last year, year and a half,
have been attacked and shut down
by various countries around the world.
And one of the big problems is that
these countries, who are so used to sovereignty,
now have this problem where, technically,
their constitutions are only local bylaws on the internet.
Right?
What applies in one country doesn't necessarily apply in another.
In France, it's illegal to sell Nazi memorabilia.
In the U.S., it's not.
Yet, Yahoo had to be shut down,
or the Nazi parts of Yahoo had to be shut down
because they were accessible to people in France.
Right?
So, I mean,
the U.S., France, China,
have all done things to shut down services of this form.
Now, to avoid turning the internet
into the lowest common denominator
of thing that is acceptable, right?
On the Cypherpunks list,
Tim May often goes off on
websites like Women Without Veils, right?
Clearly, an illegal website
in many Middle Eastern countries.
But, certainly not in the U.S., right?
Do they, should the entire internet
be watered down to what's acceptable to everyone?
Well, that would be AOL, then.
So, you've got one of those.
So, you've already got one of those.
So,
the rest of the internet
needs to be a place where communication can happen.
The point of the internet is communication.
And maybe commerce, if you believe that.
Well, maybe two years ago you would have believed that.
So, we want to be able to protect
the operators of sites like this
from persecution.
Right?
Either by adversaries,
I mean, we've seen
a lot of right-wing groups attacking
attacking certain websites.
You see, I mean, you see left-wing groups
attacking certain websites as well.
Every, many groups have other groups that
they don't like and they
flame each other and try to shut them down legally
or extra-legally.
Send big guys with
HEARF guns to their machine rooms.
Um,
so, the goal is to take the kind of privacy
that consumers are having today
that's, admittedly, in its infant stages
and be able to apply it to servers.
And the goal of this work is to be able to do that
in a way that doesn't require the redesign
of whole new technologies.
But rather take these client-side technologies
that are in their infant stages
and grow them
into technologies which can provide for
server-side anonymity.
So,
over the page.
So, I'll talk about
some different kinds of privacy-enhancing technologies.
Um,
you can take any privacy-enhancing technology
and divide them.
You can classify them in a number of ways.
One way is called mutually revealing
versus not mutually revealing.
And what that means is,
when Alice talks to Bob
using a privacy-enhancing technology,
the idea is that Eve doesn't learn the identity
of one or more of Alice and Bob.
The question is, does Bob
learn Alice's identity
and does Alice learn Bob's identity or not?
Right?
So,
um,
some privacy-enhancing technologies
let Alice and Bob know each other's identity
or require that Alice and Bob
learn each other's identity,
and some don't.
Um, by our property of the Nimity slider,
you would say that the
ones that are mutually revealing
are higher up on the Nimity slider
than the other ones,
which are not mutually revealing.
And so, by the lesson of the Ratchet,
you can see that
if you were to design a system,
you may as well design it to be
not mutually revealing,
and then,
if you want your protocol to be mutually revealing,
you just reveal the name
as part of the message.
You just send a message that Bob receives it,
the headers don't indicate who it's from,
but at the bottom it says,
signed Alice.
You just reveal the name in the message.
Um, and
the reason you design,
you should design your protocols
as low as possible on the Nimity slider,
even if you want to end up
with a protocol that's higher,
like in the pseudonymity range,
is that it lets you change your mind.
If somehow, for some reason later on,
after you've designed and fielded this protocol,
you determine,
oh, there are a few specific situations
in which I don't want pseudonymity,
but anonymity, complete anonymity is fine.
Right?
Then, it's really simple.
You just take the part of the protocol
that explicitly added in the pseudonym,
and don't do that.
But you don't have to
redesign any infrastructure
or anything like this.
So, it allows for good engineering.
So, likewise,
when we design a privacy enhancing technology,
we're going to want to do it
at the not mutually revealing level.
And then, if we want a mutually
revealing technology, we just
show the name.
Another way to
divide things
is
whether it's a
store-and-forward type of system
or an interactive type of system.
So, for a long time,
we've had things like anonymous remailers,
where you send in your message
to this big cloud.
It gets mixed up with all the other
messages coming in,
and eventually it goes out.
And the way the anonymity is
maintained is by
collecting, say,
five hours worth of messages
all over,
scrambling them up,
and then sending the results out.
But that introduces a five-hour delay
in your transmission time.
Now, let's say you want to
use that kind of method
to do World Wide Web.
So, let's say you take your TCP
SYN packet, send it in here,
after a five-hour delay, it comes out.
Suddenly your TCP
three-way handshake is
not fun anymore.
So,
we can't use those same techniques
for store and forward networks
for interactive services,
so we had to come up with new techniques.
And the new techniques
are the kinds of things that
Onion Routing, Freedom, and so on use.
And a third way
to divide things is
who does it protect?
Does it protect
the sender of a message
or the recipient of a message?
Or both?
Now, arguably,
any system designing for ongoing
back-and-forth communication
has to protect both.
Because when I send you a message,
let's say you're the one
that wants to be anonymous,
then you have to protect the recipient.
But when you reply to me,
then you're still the one
that wants to be anonymous,
so now it has to protect the sender.
So, any system designed
for ongoing communication
really needs to protect
either the identity of the sender
or the identity of the recipient.
The difference between...
So, what we say is that
we don't divide it along those lines,
but rather protection of the client
versus protection of the server.
The difference between those things
is that with a system
that protects the client,
then the client will connect
to some well-known server
with a public name.
The client will be anonymous,
but the client
will set up some short-lived
way for the server,
that one particular server only,
to reply to the client.
So that server can send
messages back to the client
without knowing who he is.
But this is a short-lived thing.
It's only for the duration of the conversation.
When the client gets bored,
he goes away and tears it down.
In contrast, when you're trying
to protect the identity of a server,
then the reply mechanism,
the way you send packets
to the anonymous party,
now has to be long-lived
and addressable.
You have to be able to figure out
how to get these packets
to this server
whose pseudonym you know,
but you don't know its real name,
its real IP address,
or anything like that.
And that is a much harder problem.
Freedom doesn't address it.
Onion routing doesn't really address it.
The idea
of this system,
of rendezvous servers,
is to provide an easy piece
of the puzzle you can snap in
that will change
that if you have a system
for protecting the privacy of a client,
it will just magically turn it into one
to protect the privacy of the server.
I'll just briefly sketch the system
because it's pretty straightforward.
I have paper online.
It's actually part of my thesis.
That goes into great detail
about all the little bits
and about how to make it
robust against failures
and malicious attacks
and nodes going up and down
which are certainly large problems
for distributed things.
So the idea,
in just a few minutes,
which is basically all I've got left,
is something we call
a rendezvous server.
And this rendezvous server
can be operated by anyone.
In much the same way
that anonymous re-mailers
are operated by anyone today.
But even more so,
the system is designed in such a way
that these rendezvous servers
can be going up and down
really fast.
And they just
very quickly
might appear,
might disappear,
and there's no requirement
that
the person that runs one today
is running it in a week from now.
So remember,
we have this system
which we'll picture by this cloud
by which
various clients
can connect through this cloud
to various services
on the internet.
And it should be impossible
or at least hard
to be able to correlate
which client is talking to which server.
That's the goal.
We'll assume we have one of those
which provides for
protection of the client.
Now we want
Alice here
to be providing an internet service.
Bob here
wants to use it.
But Alice doesn't want
to ever reveal her IP address.
So what she does is makes
an anonymous connection
to the rendezvous server.
You got a note? Okay.
Makes an anonymous connection
to the rendezvous server.
This establishes
a return channel by which packets
can go that way.
But only
for the lifetime of this connection.
Alice then,
the rendezvous server then basically
publishes an address
on which it will accept packets
and forward them to Alice.
And
how does it do that? So,
I mean one of the big problems
with anonymous services is that
anyone seen to provide the service
will be under pressure to shut it down.
Right? I mean that's the whole reason
why it was anonymous in the first place
is to prevent that kind of pressure.
So you can't just host your site on GeoCities
or something, right? Because
your adversary will just go to GeoCities
and say shut it down and GeoCities
has zero incentive not to comply.
So
you need
there not to be any central point
of attack in this system.
So
great that Alice can connect to this rendezvous
server. Why can't the rendezvous server
just be shut down now? Well the idea is
that as I said there are lots of them. People just
bring them up and put them down all the time.
they just
they're transient and you can use any
of them on the internet. So
that's great. There are now all these
rendezvous servers. How do you find them?
So now what you need is basically
a name service lookup. Some kind of database
lookup that isn't
DNS. It doesn't have
a hierarchical property.
It doesn't have a central node.
So
how does Bob, say Alice
has a service that she's advertising
with spam or something and it's called
the big bucks service.
Bob wants
to connect to the big bucks service and make
money fast.
How does Bob know where it is?
The answer
is when Alice connects to the rendezvous
server she tells it that
this is the connection for the big bucks
service. The rendezvous server
then publishes in some directory
the fact
that the big bucks services should
currently point to that port.
Or that IP address.
What is
this directory? Well this directory has
to be basically a way to
look up where files
live, where things
are. It's distributed. It's
has no centralized point of failure.
Can anyone think of something like that?
Nutella. That's a
great example. So the answer
is to how we solve
this problem is we don't and we let other
people do it for us.
There's a maxim
in computer science that says
all problems in computer science can be solved
with an additional layer of indirection.
So that's what we
do. We just
treat
Nutella itself
as a distributed file
system and
this rendezvous
server just publishes to Nutella
that, oh yeah, I've got
this, the file
rendezvous server
dash big bucks
and the contents
of that file are the IP address
of this. If you're even clever you
can say the file is rendezvous
dash big bucks dash and the IP
address and you let someone do a wild
card search to look it up.
And then there's no actual file to be
transferred. You just look up the name.
You can also put a digital signature in that name
if you want to protect from attack.
Which is really fun.
So, anyway, that then Bob
just has to
use his regular Nutella client
to look up where
the big bucks service is
and then it'll tell him it's on some port
and he connects to that port and then
the rendezvous server, all it does is shuffle
packets back and forth
between Alice and Bob. This is a
totally trivial piece of software.
It's tiny and it should
be on SourceForge as soon as
someone gets around to actually writing it.
That's the basic
way that Alice and Bob communicate.
Now, there are all sorts of
more details on
how do you handle
if Bob is connected to Alice
and has an ongoing
conversation and this rendezvous server goes away.
Right? How do you deal with that?
It turns out you can deal with that as well.
And some of the solutions require Bob
to have special software on his machine
and some don't. And of course the ones that don't are better.
This simple
piece of the puzzle here
is all that's needed
to turn
a network
which provides for client-side
anonymity into one which provides
for server-side anonymity and in a
very strong sense.
If you assume that anything
Alice connects to through the cloud
can't tell the identity of Alice
then
no one
further than that, certainly the
rendezvous server, certainly Bob,
also can't tell the identity of Alice.
And we use this
looking up in some global database,
distributed database like Nutella
to solve our name service
problem.
Seems I'm running low on time
so I'll take a few quick questions.
So the average
cycle
for metadata
distribution distributed by something
like Nutella.
Basically you can't
data
Okay, so the question is
distributed services like Nutella
generally have a longer
refresh time than
the time these rendezvous servers will be going up and down.
And that's possible and turns out not to matter much.
And the reason
is that one property
all of these services have
is the way they do their
distribution, Freenet in particular
has this property, the way they do
distribution is by caching.
Right? So originally there's
one source for the data and
as someone requests through a number of hops
each of those hops caches it.
So it's
okay in this system to have stale data.
Which is
what's useful. When a new
rendezvous server comes up, you want
that fact to be known right away.
Most of the systems have that property
that new files are visible right away.
The problem with these systems
is that old files remain visible
for a long time. But it's not a big deal.
If I want to find a rendezvous server
that's advertising big bucks
I just look for them.
I'll find five of them. Three of them might be
gone by now, but I'll try them. I'll fail
and I'll go on to the next one.
So it's
what we call in
systems soft state
as opposed to hard
state. Soft state is state that
is refreshed often,
can be dropped, it can be
replicated, it can be cached.
And basically it just acts as a
hint.
The running of the system
doesn't depend on that state being
correct all the time. And systems
with soft state are much easier to maintain.
The web address of my thesis
is you can go to my home page
at Berkeley.
It's www.csberkeley.edu
slash twiddle
i-a-n-g
and you'll be able to find obvious links to it there.
Yeah?
Right.
Right.
So the question is
I mentioned in briefly
using a digital signature to prevent
people from falsely claiming
to be the big bucks service.
So the answer
is whenever Alice
advertises her big bucks service
she puts in a public key.
So no longer can
an attacker do an attack of the form
well Alice's big bucks service
is really over here and redirect
people away.
They might put up, they might send out
their own spam saying
I have Alice Prime's big bucks
service which you can't
tell the difference and the answer
to that, that's just a marketing problem
and is also
solvable by reputation capital, right?
When Alice
tells her friend Carol about this
great big bucks, sorry when Bob tells
his friend Dave about this
great big bucks service
he's been using he should forward her
not just the name big bucks which is easy to
forge but also the public key for it.
And just
whenever the
tag gets distributed the public
key gets distributed along with it.
So I think I need to
wind things down here.
Take a quick question.
For serving anonymously.
So
right now not a lot.
So I mean there was
Mojo
which actually didn't do a lot of
anonymous.
It should. We can fix that.
We can use this to fix that.
But as I said
this is not a lot of code, right?
It's just basically a name
server and packet shuffling.
Someone with
actual copious spare time
as opposed to my copious spare time
might
very well want to just take the paper
implement the thing, stick it on
SourceForge and then let people
run with it.
I mean it's a really simple thing to do.
So I think I've got to get off the stage
because we have other people coming up
and I have this note.
